Efficiently distributing video content using a combination of a peer-to-peer network and a content distribution network

ABSTRACT

A method, system and computer program product for efficiently distributing video content. A peer-to-peer network and a content distribution network are used in combination to distribute video content. A content distribution network relies on servers distributed across the Internet to achieve high quality content delivery at a high cost. A peer-to-peer network distributes content among peers without incurring server side cost but may experience poor performance. The peer-to-peer network and the content distribution network are leveraged in a manner that achieves high content delivery and low cost by allowing the peer-to-peer network to serve as much content as possible while using the content distribution network to bootstrap the content in the peer-to-peer network and using it as a fallback whenever the peer-to-peer network has insufficient bandwidth, insufficient quality or when the missing piece of video content in the video buffer of the client device has an immediate deadline.

TECHNICAL FIELD

The present invention relates to video streaming, and more particularlyto efficiently distributing video content using a combination of apeer-to-peer network and a content distribution network.

BACKGROUND

Usage of the Internet for distribution of video is increasing inpopularity. Video traffic over the Internet may be broadly classifiedinto three categories: (1) live video streaming; (2) video on demand;and (3) video conferencing. In live video streaming, the video isbroadcasted live over the Internet which is watched by participants atapproximately the same time. In “video on demand,” users can select andwatch a video at a particular time and can even forward and rewind thevideo to an arbitrary offset. In video conferencing, users located attwo or more locations are allowed to interact via two-way video andaudio transmissions simultaneously.

Each of these services places stringent demands on the contentproviders, Internet service providers and wireless network providers toservice such needs. As a result, it is becoming increasingly difficultfor these providers to deliver high quality video content due to theirlimited network resources.

BRIEF SUMMARY

In one embodiment of the present invention, a method for efficientlydistributing video content comprises requesting from a tracker unit tojoin either an existing live streaming channel, a video on demandstreaming channel or a video conference, where the tracker unit isconfigured to keep track of active peers in a peer-to-peer network. Themethod further comprises receiving a list of active peers participatingin the live streaming channel, the video on demand streaming channel orthe video conference from the tracker unit. In addition, the methodcomprises connecting, by a processor, to a subset of peers in the listprovided by the tracker unit to become neighbors in the peer-to-peernetwork. Additionally, the method comprises receiving a missing piece ofvideo content from one of the neighbors in the peer-to-peer network orfrom a content distribution network server based on where the missingpiece of video content is to be stored in a video buffer.

Other forms of the embodiment of the method described above are in asystem and in a computer program product.

The foregoing has outlined rather generally the features and technicaladvantages of one or more embodiments of the present invention in orderthat the detailed description of the present invention that follows maybe better understood. Additional features and advantages of the presentinvention will be described hereinafter which may form the subject ofthe claims of the present invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description is considered in conjunction with thefollowing drawings, in which:

FIG. 1 illustrates a network system that combines the use of apeer-to-peer network with a content distribution network to efficientlydistribute video content in accordance with an embodiment of the presentinvention;

FIG. 2 is a hardware configuration of a client device in the networksystem in accordance with an embodiment of the present invention;

FIG. 3 is a flowchart of a method for joining an existing live streamingchannel in accordance with an embodiment of the present invention;

FIG. 4 is a flowchart of a method for leaving an existing live streamingchannel in accordance with an embodiment of the present invention;

FIG. 5 is a flowchart of a method for adding a new neighbor in apeer-to-peer network by issuing a new connection request in accordancewith an embodiment of the present invention;

FIG. 6 is a flowchart of a method for handling the connection requestdiscussed in FIG. 5 in accordance with an embodiment of the presentinvention;

FIG. 7 is a flowchart of a method for removing a new neighbor in apeer-to-peer network in accordance with an embodiment of the presentinvention;

FIG. 8 illustrates a video buffer of the client device in accordancewith an embodiment of the present invention;

FIG. 9 is a flowchart of a method for randomly selecting seed clients inaccordance with an embodiment of the present invention;

FIG. 10 is a flowchart of a method for injecting pieces from the contentsource when the peer has insufficient upload bandwidth in accordancewith an embodiment of the present invention;

FIG. 11 is a flowchart of a method for estimating the bandwidth of aclient in accordance with an embodiment of the present invention; and

FIG. 12 is a flowchart of a method for reducing the network delay usingrandom tree pushing in accordance with an embodiment of the presentinvention.

DETAILED DESCRIPTION

The present invention comprises a method, system and computer programproduct for efficiently distributing video content. In one embodiment ofthe present invention, a peer-to-peer network and a content distributionnetwork are used in combination to distribute video content. A contentdistribution network relies on servers distributed across the Internetto achieve high quality content delivery at a high cost. A peer-to-peernetwork distributes content among peers without incurring server sidecost but may experience poor performance. The use of both thepeer-to-peer network and the content distribution network are leveragedin a manner that achieves high content delivery and low cost by allowingthe peer-to-peer network to serve as much content as possible whileusing the content distribution network to bootstrap the content in thepeer-to-peer network and using it as a fallback whenever thepeer-to-peer network has insufficient bandwidth, insufficient quality orwhen the missing piece of video content in the video buffer of theclient device has an immediate deadline.

In the following description, numerous specific details are set forth toprovide a thorough understanding of the present invention. However, itwill be apparent to those skilled in the art that the present inventionmay be practiced without such specific details. In other instances,well-known circuits have been shown in block diagram form in order notto obscure the present invention in unnecessary detail. For the mostpart, details considering timing considerations and the like have beenomitted inasmuch as such details are not necessary to obtain a completeunderstanding of the present invention and are within the skills ofpersons of ordinary skill in the relevant art.

As stated in the Background section, usage of the Internet fordistribution of video is increasing in popularity. Video traffic overthe Internet may be broadly classified into three categories: (1) livevideo streaming; (2) video on demand; and (3) video conferencing. Eachof these services places stringent demands on the content providers,Internet service providers and wireless network providers to servicesuch needs. As a result, it is becoming increasingly difficult for theseproviders to deliver high quality video content due to their limitednetwork resources.

The principles of the present invention provide a means for moreefficiently distributing video content over the Internet, involving livevideo streaming, video on demand and video conferencing, using acombination of a peer-to-peer network and a content distribution networkas discussed further below in connection with FIGS. 1-11. FIG. 1illustrates a network system that combines the use of a peer-to-peernetwork with a content distribution network to efficiently distributevideo content. FIG. 2 is a hardware configuration of a client device inthe network system. FIG. 3 is a flowchart of a method for joining anexisting live streaming channel. FIG. 4 is a flowchart of a method forleaving an existing live streaming channel. FIG. 5 is a flowchart of amethod for adding a new neighbor in a peer-to-peer network by issuing anew connection request. FIG. 6 is a flowchart of a method for handlingthe connection request discussed in FIG. 5. FIG. 7 is a flowchart of amethod for removing a new neighbor in a peer-to-peer network. FIG. 8illustrates a video buffer of the client device. FIG. 9 is a flowchartof a method for randomly selecting seed clients. FIG. 10 is a flowchartof a method for injecting pieces from the content source when the peerhas insufficient upload bandwidth. FIG. 11 is a flowchart of a methodfor estimating the bandwidth of a client. FIG. 12 is a flowchart of amethod for reducing the network delay using random tree pushing.

Referring now to the Figures in detail, as stated above, FIG. 1illustrates a network system 100 that combines the use of a peer-to-peernetwork 101 with a content distribution network that uses one or morecontent distribution network servers 102 in accordance with anembodiment of the present invention. A peer-to-peer network 101 refersto distributing the tasks or workloads among peers (represented byclients 103A-103E in network 101) forming what is referred to as anetwork of nodes (where each node is represented by one of clients103A-103E). Clients 103A-103E may collectively or individually bereferred to as clients 103 or client 103, respectively. In apeer-to-peer network 101, peers or clients 103 make a portion of theirresources, such as processing power, disk storage or network bandwidth,directly available to other network participants, without the need forcentral coordination by servers or stable hosts. In the context of thevideo distribution network of the present invention, peers or clients103 make a portion of their resources available to upload video contentto other peers or clients 103 in peer-to-peer network 101 (e.g.,represented by the interconnections of clients 103 among themselves inpeer-to-peer network 101) as discussed in greater detail further below.

A content distribution network, on the other hand, refers to a system ofcomputers containing copies of data places at various nodes (representedby server 102) of a network 100. In the context of the videodistribution network of the present invention, content distributionnetwork server 102 stores video which may be downloaded by clients 103(e.g., represented by the connection between clients 103D, 103E andcontent distribution network server 102).

As a result, clients 103 may download video content from either contentdistribution network server 102 or from another client 103 viapeer-to-peer network 101. Initially, only content distribution networkserver 102 may have the video content desired by client 103. Client 103can then only download the video content from content distributionnetwork server 102. Later, such content may be distributed among otherclients 103 in peer-to-peer network 101 thereby allowing such content tobe downloaded from a client 103 within peer-to-peer network 101 insteadof from content distribution network server 102. A more detaildescription of the hardware configuration of client 103 is discussedfurther below in connection with FIG. 2.

Network 100 further includes a tracker 104, which is a computing unitconfigured to keep track of the active clients 103 in peer-to-peernetwork 101 (e.g., represented by the connection between clients 103A,103B and tracker 104) and informs a new client 103 of what other clients103 it should connect to and download content from as discussed infurther detail below.

Client 103 may be any type of device (e.g., portable computing unit,personal digital assistant (PDA), smartphone, desktop computer system,workstation, Internet appliance and the like) configured with thecapability of communicating with other clients 103, server 102 andtracker 104.

While network 100 of FIG. 1 illustrates a single peer-to-peer network101 comprising five peers or clients 103 as well as a single contentdistribution network server 102, network 100 may include any number ofpeer-to-peer networks 101 comprised of any number of clients 103 as wellas any number of servers 102 for the content distribution network.Furthermore, the interconnections between clients 103 among themselvesas well as between content distribution network server 102 and tracker104 are illustrative. The principles of the present invention are not tobe limited in scope to the topology depicted in FIG. 1.

As discussed above, FIG. 2 illustrates a hardware configuration of aclient 103 which is representative of a hardware environment forpracticing the present invention. Referring to FIG. 2, claim 103 has aprocessor 201 coupled to various other components by system bus 202. Anoperating system 203 runs on processor 201 and provides control andcoordinates the functions of the various components of FIG. 2. Anapplication 204 in accordance with the principles of the presentinvention runs in conjunction with operating system 203 and providescalls to operating system 203 where the calls implement the variousfunctions or services to be performed by application 204. Application204 may include, for example, an application for efficientlydistributing video content as discussed further below in connection withFIGS. 3-12.

Referring again to FIG. 2, read-only memory (“ROM”) 205 is coupled tosystem bus 202 and includes a basic input/output system (“BIOS”) thatcontrols certain basic functions of client 103. Random access memory(“RAM”) 206 and disk adapter 207 are also coupled to system bus 202. Itshould be noted that software components including operating system 203and application 204 may be loaded into RAM 206, which may be client's103 main memory for execution. Disk adapter 207 may be an integrateddrive electronics (“IDE”) adapter that communicates with a disk unit208, e.g., disk drive. It is noted that the program for efficientlydistributing video content as discussed further below in associationwith FIGS. 3-12, may reside in disk unit 208 or in application 204.

Client 103 may further include a communications adapter 209 coupled tobus 202. Communications adapter 209 may interconnect bus 202 with anoutside network thereby enabling client 103 to communicate with othersimilar devices.

I/O devices may also be connected to client 103 via a user interfaceadapter 210 and a display adapter 211. Keyboard 212, mouse 213 andspeaker 214 may all be interconnected to bus 202 through user interfaceadapter 210. Data may be inputted to client 103 through any of thesedevices. A display monitor 215 may be connected to system bus 202 bydisplay adapter 211. In this manner, a user is capable of inputting toclient 103 through keyboard 212 or mouse 213 and receiving output fromclient 103 via display 215 or speaker 214.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” ‘module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or flash memory), a portablecompact disc read-only memory (CD-ROM), an optical storage device, amagnetic storage device, or any suitable combination of the foregoing.In the context of this document, a computer readable storage medium maybe any tangible medium that can contain, or store a program for use byor in connection with an instruction execution system, apparatus, ordevice.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the C programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of thepresent invention. It will be understood that each block of theflowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to product a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunction/acts specified in the flowchart and/or block diagram block orblocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the function/acts specified in the flowchart and/or blockdiagram block or blocks.

As discussed above, video traffic over the Internet may be broadlyclassified into three categories: (1) live video streaming; (2) video ondemand; and (3) video conferencing. In connection with live videostreaming, clients 103 may establish and manage its own peer-to-peernetwork topology using the principles of the present invention asdiscussed below in connection with FIGS. 3-7.

FIG. 3 is a flowchart of a method 300 for joining an existing livestreaming channel in accordance with an embodiment of the presentinvention.

Referring to FIG. 3, in conjunction with FIGS. 1 and 2, in step 301,client 103 sends a request to tracker 104 to join an existing livestreaming channel.

In step 302, client 103 receives a list of active peers in the livestreaming channel. In one embodiment, tracker 104 may take into accountthe geographical location of client 103 in deciding which subset ofpeers/clients 103 to provide to the requesting client 103.

In step 303, client connects to a random subset of peers provided bytracker 104 to become neighbors in its own peer-to-peer network 101.That is, after client 103 receives a list of N peers from tracker 104,client 103 connects to a random subset of K peers to become theirneighbors in peer-to-peer network 101. To prevent peers from formingoverly dense clusters, K is chosen as K=min{N^(Topology) ^(—)^(Exponent), Min_Node_Degree}, where Topology_Exponent andMin_Node_Degree are configurable parameters. Min_Node_Degree is aconfigurable parameter referring to the minimum number of nodes to beconnected in peer-to-peer network 101 by client 103 for ensuring thatpeer-to-peer network 101 is well-connected so that “pieces” (a portionof the video content), discussed further below, can propagate quickly(e.g., Min_Node_Degree=10). In one embodiment, Topology_Exponent rangesfrom 0.5 to 1.

In step 304, client 103 determines whether the number of peers receivedby tracker 104 is less than a threshold number, Min_Peer_Number. In oneembodiment, Min_Peer_Number=Min_Node_Degree^((1/Topology) ^(—)^(Exponent)). If the number of peers returned by tracker 104 is lessthan Min_Peer_Number, then, in step 305, client 103 requestsperiodically from tracker 104 more peers to form part of client's 103peer-to-peer network 101. Additionally, client 103 may discover morepeers in the live streaming channel by exchanging peer information withits neighbors.

If, however, the number of peers returned by tracker 104 is not lessthan Min_Peer_Number, then, in step 306, client 103 does not requestfrom tracker 14 more peers to form part of client's 103 peer-to-peernetwork 101.

In some implementations, method 300 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 300 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 3 isillustrative. Additionally, in some implementations, certain steps inmethod 300 may be executed in a substantially simultaneous manner or maybe omitted.

In connection with client 103 leaving an existing live streamingchannel, the following method is performed.

FIG. 4 is a flowchart of a method 400 for leaving an existing livestreaming channel in accordance with an embodiment of the presentinvention.

Referring to FIG. 4, in conjunction with FIGS. 1 and 2, in step 401,client sends a leave notification message to tracker 104.

In step 402, client 103 disconnects all its neighbors in itspeer-to-peer network 101.

In step 403, tracker 104 removes client 103 from its list of activepeers whenever it receives a leave notification message from client 103or when it fails to receive any keep-alive message from client 103 forPeer_Keep_Alive_Interval seconds (where Peer_Keep_Alive_Interval is aconfigurable parameter) (e.g., Peer_Keep_Alive_Interval is 30 seconds).In one embodiment, client 103 periodically sends keep-alive messages toinform tracker 104 that it is alive and the number of extra neighbors103 is willing to accept.

In some implementations, method 400 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 400 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 4 isillustrative. Additionally, in some implementations, certain steps inmethod 400 may be executed in a substantially simultaneous manner or maybe omitted.

In connection with client 103 adding a new neighbor in its peer-to-peernetwork 101 in the context of live streaming, the following method isperformed.

FIG. 5 is a flowchart of a method 500 for adding a new neighbor in apeer-to-peer network 101 by issuing a new connection request inaccordance with an embodiment of the present invention.

Referring to FIG. 5, in conjunction with FIGS. 1 and 2, in step 501, adetermination is made as to whether the number of neighbors in client's103 peer-to-peer network 101 is below a threshold. In one embodiment,the threshold K=min(N^(Topology) ^(—) ^(Exponent), Min_Node_Degree),where N is the total number of peers that client 103 currently knows(i.e., the number of peers in client's 103 peer-to-peer network 101). Inone embodiment, Max_Node_Degree is chosen to ensure that the controloverhead (due to e.g., the keep-alive messages) is not too burdensome.For example, Max_Node_Degree may be set to equal 15.

If the number of neighbors client 103 knows is below a threshold, then,in step 502, client 103 periodically tries to increase its number ofneighbors by connecting to more peers.

If, however, the number of neighbors in client's 103 peer-to-peernetwork 101 is not below a threshold, then, in step 503, client 103 doesnot attempt to connect to more peers and reject all subsequentconnection requests from peers.

In some implementations, method 500 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 500 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 5 isillustrative. Additionally, in some implementations, certain steps inmethod 500 may be executed in a substantially simultaneous manner or maybe omitted.

FIG. 6 is a flowchart of a method 600 for handling the connectionrequest discussed in method 500 in accordance with an embodiment of thepresent invention.

Referring to FIG. 6, in conjunction with FIGS. 1, 2 and 5, in step 601,client 103 receives a connection request as discussed in connection withmethod 500. In step 602, a determination is made as to whether thenumber of neighbors in client's 103 peer-to-peer network 101 is below athreshold. In one embodiment, Max_Node_Degree is chosen to ensure thatthe control overhead (due to e.g., the keep-alive messages) is not tooburdensome. For example, Max_Node_Degree may be set to equal 15.

If the number of neighbors client 103 knows is below a threshold, then,in step 603, client 103 accepts the peer's connection request.Otherwise, in step 604, client 103 does not accept the peer's connectionrequest.

In some implementations, method 600 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 600 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 6 isillustrative. Additionally, in some implementations, certain steps inmethod 600 may be executed in a substantially simultaneous manner or maybe omitted.

In connection with removing an existing neighbor in its peer-to-peernetwork 101 in the context of live streaming, the following method isperformed.

FIG. 7 is a flowchart of a method 700 for removing a new neighbor in apeer-to-peer network 101 in accordance with an embodiment of the presentinvention.

Referring to FIG. 7, in conjunction with FIGS. 1 and 2, in step 701,client 103 determines if a peer is considered dead. “Dead,” as usedherein, refers to a client 103 acting as a peer that does not provide akeep-alive message over a duration of time. In one embodiment, client103 and its neighbors in its peer-to-peer network 101 periodicallyexchange keep-alive messages to inform each other that they are alive(e.g., once per second). In one embodiment, a neighbor is considereddead if no keep-alive message from the peer is received over the pastNeighbor_Keep_Alive_Interval seconds (where Neighbor_Keep_Alive_Intervalis a configurable parameter; e.g., Neighbor_Keep_Alive_Interval=20seconds).

If a peer is considered dead, then, in step 702, client 103 removes thepeer from its peer-to-peer network 101.

If, however the peer is not considered dead, then, in step 703, client103 determines if the performance of the peer is unsatisfactory. Forexample, the rate of loss video content between the peer and client 103is deemed to be too high. In another example, the bandwidth of the peeris too low. In a further example, the response time of the peer is tooslow.

If the performance of the peer is deemed to be unsatisfactory, then, instep 702, client 103 removes the peer from its peer-to-peer network 101.

If, however, the performance of the peer is not deemed to beunsatisfactory, then client 103 continues to determine if a peer isconsidered dead in step 701.

In some implementations, method 700 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 700 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 7 isillustrative. Additionally, in some implementations, certain steps inmethod 700 may be executed in a substantially simultaneous manner or maybe omitted.

While the previous discussion of FIGS. 3-7 were directed to live videostreaming, the principles of the present invention discussed inconnection with FIG. 3-7 may be applied to the other categories of videotraffic, namely, video on demand and video conferencing.

As discussed above, video traffic over the Internet may be broadlyclassified into three categories: (1) live video streaming; (2) video ondemand; and (3) video conferencing. For all such cases of video traffic,the principles of the present invention divide the video content intowhat are called herein as “pieces.” Each piece may last for a designatedperiod of time, which is represented by the parameter, Piece_Duration.Piece_Duration is a configurable parameter (for example,Piece_Duration=0.25 second). In one embodiment, each piece contains atimestamp that specifies the offset of the piece within a video stream.

In one embodiment, each client 103 divides its video buffer into thefollowing four parts as shown in FIG. 8. FIG. 8 illustrates a videobuffer 800 in accordance with an embodiment of the present invention.

Referring to FIG. 8, in conjunction with FIG. 1, video buffer 800comprises a back buffer 801 storing what is referred to herein as the“back buffer pieces.” In one embodiment, back buffer 801 stores recentlyplayed pieces. Back buffer 801 may provide pieces for any peer whoseplay point is less than the current client's 103 play point. For livestreaming and video conferencing, the size of back buffer 801,represented by the parameter, Back_Buffer_Size, is typically small(e.g., a few seconds). For video on demand, Back_Buffer_Size can be 5-10minutes or even longer (if there is enough memory available). In oneembodiment, it may be desirable to keep Back_Buffer_Size below 10minutes so as to it make it possible to support high-definition videos,which have much higher data rates and thus impose much higher memoryrequirement. To further reduce buffer requirement, one may keep a randomfraction of recently played pieces as will be discussed in furtherdetail below in connection with buffer management for video on demand.

Video buffer 800 further includes a source protection window 802. Sourceprotection window 802 contains pieces whose deadlines (that is,scheduled play times) are within Source_Protection_Window_Size(parameter representing the size of source protection window 802) piecesfrom the current play point 803. To assure the quality of videostreaming, any missing piece in source protection window 802 will befetched directly from the content source, such as content distributionnetwork server 102. In one embodiment, Source_Protection_Window_Size isset to be very small (typically a few seconds) to minimize the amount ofcontent directly served by the original source, such as contentdistribution network server 102.

Video buffer 800 additionally includes a window of time, referred toherein as the urgent window 804. Urgent window 804 contains pieces whosedeadlines (that is, scheduled play times) are within Urgent_Window_Size(parameter representing the size of urgent window 804) pieces after theend of source protection window 802. Missing pieces in urgent window 804are fetched from neighbors in an earliest-deadline-first fashion asdiscussed in further detail below. In one embodiment, theUrgent_Window_Size typically lasts for only a few seconds.

Additionally, video buffer 800 includes a window of time, referred toherein as the front buffer 805. Front buffer 805 contains pieces whosedeadlines (that is, scheduled play times) are within Front_Buffer_Size(parameter representing the size of front buffer 805) pieces after theend of urgent window 804. Missing pieces in front buffer 805 are fetchedboth from the content source, such as content distribution networkserver 102 (using the direct content injection algorithm describedbelow), and from neighboring clients 103 (using the piece schedulingalgorithm described below). In one embodiment, for live streaming,Front_Buffer_Size lasts for only a few seconds; for video conferencing,Front_Buffer_Size only lasts for no more than a second; for video ondemand, the size of the Front_Buffer_Size depends on the largest playpoint difference between client 103 and all its neighbors. A discussionas to how to choose Front_Buffer_Size for video on demand is providedfurther below.

Video buffer 800 is maintained as a sliding window. That is, as playpoint 803 moves forward, the entire buffer shifts forward accordingly.All missing pieces inside source protection window 802 will be fetcheddirectly from the content source; missing pieces in urgent window 804will only be fetched from peers; missing pieces in front buffer 805 willbe fetched from both the content source and from the peers. The detailsfor determining which piece to next fetch are provided below inconnection with the “piece scheduling algorithm.” Furthermore, thedetails for determining from which peer to request a missing piece isdiscussed further below in connection with the “peer selectionalgorithm.”

Referring again to FIG. 8, in conjunction with FIG. 1, differentscheduling algorithms are used to decide which missing piece to nextfetch based on which part of video buffer 800 contains the missingpiece.

When the missing piece is in front buffer 805, the missing piece isfetched from neighboring clients 103 in a rarest-latest-first fashion.Specifically, a client 103 computes Count(p), the number of clients 103within client's 103 1-hop neighborhood that already have piece p. Themissing pieces are then sorted in ascending order of Count(p) (thus,“rarest first” is used as the primary order), and when multiple pieceshave the same Count(p)), they are sorted in descending order of theirtimestamps (thus, “latest first” is used to break ties).

When the missing piece is in urgent window 804, the missing piece isfetched from neighboring clients 103 in an earliest-deadline-firstfashion. Specifically, the missing pieces with the earliest scheduledplay time are fetched first. In one embodiment, with probabilityUrgent_Window_Probability, missing pieces in urgent window 804 arefetched before missing pieces in front buffer 805 are fetched; withprobability 1—Urgent_Window_Probability, missing pieces in front buffer805 are fetched before missing pieces in urgent window 804 are fetched.In one embodiment, Urgent_Window_Probability is a configurable parameterbetween 0 and 1 that controls the relative importance of urgent window804 versus front buffer 805. In one embodiment,Urgent_Window_Probability=1.

In the scenario when the same piece is available at multiple peers, thepeers with a higher bandwidth, low latency are more preferable.Specifically, let P[k1], P[k2], . . . , P[ku] be the set of peers thatown a piece p. Client 103 selects a random peer with a probabilityproportional to their upload bandwidth to request the piece p. In oneembodiment, the peer can be selected by computing randomized weightsW[ki]=log(uniform(P[ki], C, p))/bw[ki] and finding the peer with thelargest randomized weights W[ki], where C designates a client 103 and bwdesignates a bandwidth. Moreover, client 103 does not fetch from aneighbor when the neighbor's predicted response time is too highcompared with the deadline (i.e., scheduled play time) for a givenpiece.

As previously discussed, there are times when the content needs to beprovided or “injected” from the content source, such as contentdistribution network server 102. For example, missing pieces in sourceprotection window 802 will be fetched directly from the content source.Also, missing pieces in front buffer 805 may be fetched from the contentsource using the direct content injection algorithm as discussed below.

There are three main scenarios in which it is useful to directly injectvideo content from the content source, such as content distributionnetwork server 102, into clients 103. A piece needs to be first injectedfrom the content source into a subset of clients 103, which are called“seed clients” for the piece herein, before it can be furtherdisseminated among all the clients 103 in a peer-to-peer fashion. When apiece propagates too slowly due to insufficient peer upload bandwidth,the content source needs to inject pieces into more clients 103 and helpincrease the total upload bandwidth and thus improve the disseminationspeed. Furthermore, when a piece is about to miss its deadline (i.e., ascheduled play time) at a client 103, client 103 should directly fetchthe piece from the content source in order to assure high video quality.In this manner, the amount of video content serviced directly by thecontent source, such as content distribution network server 102, isminimized while assuring high video quality for all clients 103.

Pieces inside source protection window 802 have immediate deadlines(i.e., a scheduled play time). To assure high video quality, any missingpiece inside source protection window 802 is fetched directly from thecontent source in an earliest-deadline-first fashion. That is, missingpieces with the earliest scheduled play times are fetched first.

Whenever a new piece becomes available, a subset of seed clients willfetch the piece directly from the content source. These seed clients canthen further disseminate the piece to other clients 103 in apeer-to-peer fashion. In one embodiment, a configurable parameterSeed_Client_Fraction is used to specify the desired fraction of seedclients (e.g., Seed_Client_Fraction=5%). To achieve load balancing, theseed clients for each piece are chosen randomly with probabilitiesproportional to their upload bandwidth (estimated using the bandwidthestimation algorithm as discussed further below). To avoid globalcoordination, the following distributed randomized seed client selectionalgorithm (method 900) is used as discussed in conjunction with FIG. 9.

FIG. 9 is a method 900 for randomly selecting seed clients in accordancewith an embodiment of the present invention.

Referring to FIG. 9, in conjunction with FIGS. 1 and 8, in step 901,client 103 periodically receives information about their neighbor listsand their estimated upload bandwidth. In this way, client 103 candiscover all the neighbors/peers within its H-hop neighborhood (i.e.,the peers whose shortest path distance to client 103 in its peer-to-peernetwork 101 is at most H). To reduce control overhead, H can be set to arelatively small value (e.g., H=1 or 2).

In step 902, client 103 computes a randomized weight for the uploadbandwidth of its neighbors. Let the discovered peers be: P[1], P[2] . .. , P[n]. Let the upload bandwidth for peer P[k] be bw[k]. Forconvenience, let P[0]=C (client 103) and bw[0] be the upload bandwidthfor C. For a given piece with timestamp p, for each k=0, 1, . . . , n, Ccomputes a randomized weight

W[k]=log(uniform(P[k], C, p))/bw[k],

where uniform(P[k], C, p) returns a pseudo random number uniformlydistributed between 0 and 1 by using tuple (P[k], C, p) as the randomseed for the pseudo random number generator.

In step 903, client 103 selects the seed clients based on the computedrandomized weight. Client 103 selects itself to become a seed node for apiece if and only if its own random weight W[0] is among(1+n)*Seed_Client_Fraction largest values in the entire set of randomweights {W[k]|k=0, 1, . . . , n}. Note that the choice of random weightsensures that the probability for W[i]>W[j] is equal tobw[i]/(bw[i]+bw[j]) for any i≠j. Hence the probability for W[k] to beamong the (1+n)*Seed_Client_Fraction largest weights is proportional tobw[k].

In some implementations, method 900 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 900 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 9 isillustrative. Additionally, in some implementations, certain steps inmethod 900 may be executed in a substantially simultaneous manner or maybe omitted.

When there exists the situation of a peer not having sufficient uploadbandwidth, client 103 performs the following method to inject themissing pieces from the content source, such as content distributionnetwork server 102.

FIG. 10 is a method 1000 for injecting pieces from the content sourcewhen the peer has insufficient upload bandwidth in accordance with anembodiment of the present invention.

Referring to FIG. 10, in conjunction with FIGS. 1 and 8, in step 1001,client 103 exchanges piece availability via a bitmap with otherneighbors/peers in peer-to-peer network 101. In one embodiment,neighbors periodically exchange bitmaps that summarize pieceavailability in their video buffers 800 once everyBitmap_Exchange_Interval seconds (where Bitmap_Exchange_Interval is aconfigurable parameter). In one embodiment, a bitmap refers to a binaryvector where a “one” indicates a piece is available and a “zero”indicates a piece is missing. The bitmap also contains the current playpoint information (i.e., play point 803). In addition, bitmaps may bepiggybacked to any piece request message or data message exchanged amongpeers. To reduce communication overhead, the complete bitmap may only beexchanged when the Bitmap_Exchange_Timer expires periodically. Duringthe interval after the Bitmap_Exchange_Timer expires and before itexpires again, all control and data messages only specify changes to themost recent complete bitmap.

In step 1002, client 103 computes the per-piece bandwidth deficit. LetP[1], P[2] . . . , P[n] be client's 103 direct neighbors. Let P[0]=C (C,referring to client 103). Let the upload bandwidth for P[k] be bw[k].Let BW=bw[0]+bw[1]+ . . . +bw[n] be the total upload bandwidth withinthe 1-hop neighborhood of C. For a given piece with timestamp p, letCount(p) be the number of clients in set {P[k]|k=0, 1, . . . , n} thatalready have the piece. Let Data_Rate be the data rate of the videostream. The bandwidth deficit for piece p can then be computed asDeficit(p)=(1+n−Count(p))*Data_Rate−BW, where (1+n−Count(p))*Data_Raterepresents the total demand for downloading, and BW represents the totalsupply of upload bandwidth. It is noted for clarity that the per-piecebandwidth deficit can be either positive or negative. When Deficit(p) ispositive, it indicates that p has insufficient upload bandwidth. In thismanner, each client 103 determines which pieces cannot be provided by apeer due to insufficient upload bandwidth thereby requiring directinjection from the content source. When Deficit(p) is negative, itindicates that p has more upload bandwidth than what is needed fordisseminating piece p. Such surplus bandwidth can then be used todisseminate other pieces.

In step 1003, client 103 computes the cumulative bandwidth deficit. Inorder to efficiently utilize all the surplus bandwidth and minimize thedistinct number of pieces that require direct injection from the contentsource, client 103 first sorts all the pieces in a rarest-latest-firstfashion. Specifically, client 103 sorts pieces in ascending order ofCount(p) (thus, “rarest first” is used as the primary order), and whenmultiple pieces have the same Count(p)), sort such pieces in descendingorder of their timestamps (thus, “latest first” is used to break ties).Let the sorted pieces be p1, p2, . . . , pm. Sorting inrarest-latest-first order ensures that p1 has the highest per-piecedeficit and pm has the lowest per-piece deficit. For each piece pj,client 103 then computes the cumulative bandwidth deficit.

In step 1004, client 103 determines if the cumulative bandwidth deficitis positive. Whenever the cumulative bandwidth deficit is positive,client 103, in step 1005, computes the inject count, Inject_Count(pj),i.e., the number of copies pj needs to be injected from the contentsource into client's 103 1-hop neighborhood, using the followingalgorithm (AG 1):

cum_deficit = 0 for j = m down to 1 cum_deficit = cum_deficit +Deficit(p_(j)) if (cum_deficit > 0) Inject_Count(p_(j)) = cum_deficit /Data_Rate cum_deficit = 0 else Inject_Count(p_(j)) = 0 end if end for

All pieces with Inject₁₃ Count(pj)>0 require direct injection insideclient's 103 1-hop neighborhood.

If, however, the cumulative deficit is not positive, then, in step 1006,client 103 does not need to inject pieces from the content source, suchas content distribution network server 102.

Returning to step 1005, client 103, in step 1007, selects the peerswithin client's 103 1-hop neighborhood that need to directly inject pjfrom the content source, such as content distribution network server102. It is noted that Inject_Count(pj) only specifies the total numberof additional clients within client's 103 1-hop neighborhood that needto directly inject pj from the content source. It does not specify whichclient 103 needs to inject piece pj. In order for client 103 todetermine whether itself is one of these clients who need to injectpiece pj, client 103 applies the same distributed, randomized seedclient selection algorithm described above. Specifically, client 103first computes randomized weights W[k]=log(uniform(P[k], C, pj))/bw[k],where uniform(P[k], C, pj) returns a pseudo random number uniformlydistributed between 0 and 1 by using tuple (P[k], C, pj) as the randomseed. Client 103 then decides to inject piece pj if and only if W[0] isamong the top Inject_Count(pj) largest weights among all the W[k] (k=0,1, . . . , n). When client 103 decides to inject more than one piece, itfetches them from the content source in a rarest-latest-first fashion.

In some implementations, method 1000 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 1000 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 10 isillustrative. Additionally, in some implementations, certain steps inmethod 1000 may be executed in a substantially simultaneous manner ormay be omitted.

In order to ensure that the peers are not overloaded in uploading videotraffic to other peers in peer-to-peer network 101, the following isapplied.

Upload traffic sending rate may have to be throttled, because otherwisethere can be significant queue buildup, which can cause excessivenetwork delay and even packet losses. A standard token bucket may beused to limit the delay and burstiness of the upload data traffic. Inone embodiment, the control traffic has a higher priority and is notsubject to the rate limiting. Not throttling control traffic isreasonable because control traffic rate is low and will not causecongestion in general. Moreover, most control traffic requires low delayin order to be effective and cannot be queued after data traffic. Byrate limiting the upload traffic, creating long queues in a large hiddenbuffer (e.g., upstream of a digital subscriber line or a cable modemlink) may be avoided.

In one embodiment, the token bucket has the following configurableparameters:

(i) Token_Generation_Rate=Upload_BW, which limits the average uploadtraffic rate;

(ii) Token_Bucket_Capacity=Upload_BW*Token_Bucket_Max_Burst_Delay, whichlimits the maximum burst size (and thus the queueing delay at the truebottleneck). Token_Bucket_Max_Burst_Delay is typically set to a smallvalue (e.g., 200 milliseconds) to avoid sending a large burst of datapackets into the network, which may overflow router buffers; and

(iii) When there is insufficient token available, the packet is enteredinto a queue, which has capacityQueue_Capacity=Upload_BW*Token_Bucket_Max_Queue_Delay. The queue lengthaffects the maximum end-to-end delay. When the queue is full, the packetis dropped and an explicit loss notification message is sent to theneighbor who requests the data. Token_Bucket_Max_Queue_Delay is alsokept relatively small (e.g., 500 milliseconds) to minimize end-to-enddelay. For video conferencing, which has a more stringent delayrequirement, Token_Bucket_Max_Queue_Delay can be further reduced tominimize end-to-end latency.

In order to ensure that clients 103 are not overloaded in downloadingvideo traffic from other peers in peer-to-peer network 101 or from thecontent source, the following is applied.

Since traffic may be downloaded either from the content source oranother client 103 and the content source may be out of our directcontrol, download traffic cannot be directly controlled. Instead, therequest rate generated from a peer is throttled, which in turn throttlesthe download traffic since traffic is downloaded in response torequests. An Additive Increase Multiplicative Decrease (AIMD) scheme isused to adjust the Request_Quota for each peer. Request_Quota refers toa configurable parameter that specifies a limit as to the number ofpieces that may be downloaded over a period of time.

In the AIMD scheme, the first part of the scheme is referred to as theadditive increase. Specifically, when (i) a piece is successfullydownloaded from a neighbor P, and (ii) the current number of unansweredrequests for neighbor P is greater than Request_Quota(P)−1, client 103increases Request_Quota(P) toRequest_Quota(P)+AIMD_Alpha/Request_Quota(P). The second conditionessentially states that Request_Quota(P) is saturated. AIMD_Alpha is aconfigurable parameter that controls the speed of additive increase. Inone embodiment, AIMD_Alpha=1. In addition, Request_Quota(P) is upperbounded by the bandwidth-delay product BW(P)*RTT, where BW(P) is theestimated upload bandwidth of peer P, and RTT is the estimatedround-trip-time between the current client 103 and neighbor P.

The second part of the AIMD scheme involves the multiplicative decrease.When either (i) an unanswered request is timed out, or (ii) an explicitloss notification message is received from P (generated when P is ratelimiting its upload traffic), Request_Quota(P) is reduced toRequest_Quota(P)*AIMD_Beta. In one embodiment, AIMD_Beta is aconfigurable parameter between 0 and 1 that controls the speed ofmultiplicative decrease. In one embodiment, AIMD_Beta=½. In oneembodiment, Request_Quota(P) is lower bounded by 1.

To further control congestion using the network architecture of network100, the number of concurrent downloads from the content source, such ascontent distribution network server 102 may be limited. In order toavoid overloading the content source, each client 103 limits the numberof concurrent downloads from the content source by the parameterSource_Concurrent_Download_Limit. In one embodiment, a possible choiceof Source_Concurrent_Download_Limit is 6, because most modern browsers(e.g., Firefox®, Chrome®, Internet Explorer®, Safari®) limit the numberof concurrent HTTP connections to 6 or higher.

As discussed above, the knowledge of network bandwidth at clients 103 isused for peer-to-peer network formulation as well as congestion control.Suppose client 103 has n neighbors P[1], P[2], . . . , P[n]. Thefollowing method is used to estimate BW(C): the total upload bandwidthof C, where C refers to a client 103.

FIG. 11 is a method 1100 for estimated the bandwidth of a client 103 inaccordance with an embodiment of the present invention.

Referring to FIG. 11, in conjunction with FIG. 1, in step 1101, client103 sets msg.send_time to the current time of day based on client's 103local clock whenever client 103 sends a message msg (either data orcontrol) to a neighbor P[i].

In step 1102, P[i] sets msg.recv_time to the current time of dayaccording to P[i]'s local clock when P[i] receives the message of step1001.

In step 1103, P[i] computes the one-way delay for msg as:

OWD(msg)=msg.recv_time−msg.send_time

Note that client's 103 local clock and P[i]'s local clock need not besynchronized. As a result, the absolute value of OWD(msg) may not bevery meaningful. For example, the value of OWD(msg) may be negative.However, it is assumed that client's 103 and P[i]'s clocks will notdrift apart too quickly. That is, the offset between client's 103 localtime and P[i]'s local time stay roughly constant.

In step 1104, each neighbor P[i] keeps track ofMinOWD(C,P[i])=min{OWD(msg)|msg is a control message from client 103 toP[i]}, which is the minimum one-way delay for control messages sent fromclient 103 to P[i]. Examples of a control message includes: a keep-alivemessage, a bitmap exchange message, a piece request message, an explicitloss notification message, etc.

In step 1105, for each data message msg from client 103 to P[i] withpayload length msg.len, P[i] can obtain a bandwidth estimate as:

bw(msg)=msg.len/(OWD(msg)−MinOWD(C,P[i])),

where the denominator OWD(msg)−MinOWD(C, P[i]) represents an estimate ofthe time it takes to transmit the data contained in msg.

In step 1106, P[i] estimates the bandwidth from client 103 to P[i] asthe largest estimate from all the data messages sent from client 103 toP[i] over the past Bandwidth_Estimation_Interval. That is,bw(C,P[i])=max{bw(msg)|msg is received in the pastBandwidth_Estimation_Interval}, where Bandwidth_Estimation_Interval is aconfigurable parameter with a sufficiently long duration (e.g., 10minutes).

In step 1107, P[i] sends bw(C,P[i]) as an attribute in its controlmessages to client 103.

In step 1108, client 103 estimates its upload BW as the largestbandwidth estimate among all its neighbors. That is,BW(C)=max{bw(C,P[i])|i=1, 2, . . . , n}.

It is noted that MinOWD(C, P[i]) may be unreliable if there are notenough OWD samples. In particular, if MinOWD(C, P[i]) is overestimated,then the upload BW can be overestimated. To solve this problem, when thenumber of OWD samples is below a threshold, Min_OWD_Samples (e.g., 30),P[i] conservatively estimates BW based on the round-trip time:bw(msg)=msg.len/RTT(msg), where the round-trip time RTT(msg) iscalculated as the lag between the time when a piece is requested by P[i]and the time when the response msg is received by P[i].

In some implementations, method 11000 may include other and/oradditional steps that, for clarity, are not depicted. Further, in someimplementations, method 1100 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 11 isillustrative. Additionally, in some implementations, certain steps inmethod 1100 may be executed in a substantially simultaneous manner ormay be omitted.

As discussed above, video traffic over the Internet may be broadlyclassified into three categories: (1) live video streaming; (2) video ondemand; and (3) video conferencing. While the above description relatedto live video streaming, the principles of the present inventiondiscussed above may be applied to video on demand and video conferencingas discussed below.

In connection with supporting video on demand, the system of the presentinvention can be extended to support video on demand with the followingmodifications.

Referring to FIGS. 1 and 8, in live streaming, peer-to-peer networkformation is performed according to network proximity. In video ondemand, clients 103 differ not only in their proximity but also in theirplay points 803. Clients 103 that watch adjacent play points 803 canshare the content more efficiently. Motivated by this observation, thepeer-to-peer network formation algorithm discussed above in connectionwith FIGS. 3-7 is modified to take into account of both proximity andplay points 803. Specifically, when a new client 103 joins the network,tracker 104 returns a list of nodes (referring to other clients 103 innetwork 100) whose play points 803 differ from the new client 103 withinX-minute(s) and have a small network round-trip time to the new client103 as the new client's 103 peers, where X is a configurable parameter(e.g., X=5 or 10 minutes). If there are too few clients 103 whose playpoints 803 are within X minutes, tracker 104 simply returns thoseclients 103 whose play points 803 are the closest to the new client'splay point 803.

With respect to buffer management, the size of the front buffer needs tobe configured differently. In live streaming, the Front_Buffer_Size(size of front buffer 805) is set to a relatively small value (e.g., afew seconds). For video on demand, the Front_Buffer_Size needs to belarge enough so that client 103 that starts viewing the video later canfetch pieces that are not yet viewed by an earlier client 103. This cansignificantly improve the fraction of peer-delivered content especiallywhen the later client 103 has higher upload bandwidth and otherresources. The system of the present invention automatically selects theFront_Buffer_Size as follows:

Front_Buffer_Size(C)=max{Min_FBS, min{Max_FBS,max {Playpoint(P_(k))−Playpoint(C)|P _(k) is a direct neighbor of C}}

This means that the Front_Buffer_Size(C) has a lower bound of Min_FBSand an upper bound of Max_FBS. The actual size of front buffer 805 isalso determined by the largest difference between the neighbors' playpoint 803 and client 103's own play point 803. If all the neighbors playpoints 803 are behind the play point 803 of client 103, then client 103only needs to buffer Min_FBS. Otherwise, client 103 needs to bufferpossibly more data for its neighbor to download. In one embodiment,Min_FBS can be set to a small value (e.g., 10 seconds), and Max_FBS canbe set to a larger value (e.g., 5-10 minutes).

With respect to managing back buffer 801, back buffer 801 stores piecesthat have been recently played. So long as memory is available, one canmake the size of back buffer 801 as large as possible. For example, whenthe application of the present invention runs inside a browser, it isoften deemed safe when the entire video buffer consumes less than 50-70MB. The Back_Buffer_Size (size of back buffer 801) should be made largeenough to cover the maximum play point difference between neighbors. Forexample, if tracker 104 ensures the maximum play point difference isbelow 5-10 minutes, then back buffer 801 only needs to span 5-10minutes.

Note that client 103 has the option to keep only a subset of piecesinside back buffer 801. For example, for each piece p inside back buffer801, client 103 can generate a random number uniform(p, C), which isuniformly distributed between 0 and 1 and uses pair (p, C) as the randomseed, where C represents client 103. Client 103 then only keeps a piecep when uniform(p, C) is below a configurable thresholdBack_Buffer_Density (e.g., value between 0 and 1). In this way, theexpected number of pieces occupied by back buffer 801 is onlyBack_Buffer_Size*Back_Buffer_Density. By reducing Back_Buffer_Density,back buffer 801 can span a wider time range without increasing thememory consumption. This technique is particularly useful for supportinghigh-definition videos where each piece may be very large. The techniqueis also useful for less popular videos, where play points 803 betweenneighbors may differ by much more than 5-10 minutes.

Finally, after client 103 starts playing for some time, its directneighbor set may become sufficiently stable. This can happen whenclient's 103 neighbor count reaches the upper bound of Max_Node_Degreeor when the neighbor set stops changing for Y minutes (e.g., Y=5-10). Inthis case, client 103 can adjust its back buffer size based on themaximum difference between neighbors' play points 803 and client's ownplay point 803. Specifically, one can set

Back_Buffer_Size(C)=max{Min_BBS,

-   -   min{Max_BBS,        -   max{Playpoint(C)−Playpoint(P_(k))|P_(k) is a direct neighbor            of C}}.

This means that Back_Buffer_Size(C) has a lower bound of Min_BBS and anupper bound of Max_BBS. The actual back buffer size is also determinedby the largest difference between the neighbors' play point 803 andclient's own play point 803. If all the neighbors play points 803 arebefore (i.e., greater than) play point 803 of client 103, then client103 only needs to buffer Min_BBS. Otherwise, client 103 needs to bufferpossibly more data for its neighbor to download. In one embodiment,Min_BBS can be set to a small value (e.g., 10 seconds), and Max_BBS canbe set to a larger value (e.g., 5-10 minutes).

Furthermore, video on demand allows client 103 to perform a forward orbackward seek operation. If after client 103 performs a forward orbackward seek operation, the new play point 803 is still within Max FBSfrom the neighbors' play points 803, then there is no need to changeclient's 103 neighborhood. The only thing it requires is for client 103to readjust the Front_Buffer_Size(C) based on the new play point 803.Client 103 also needs to inform its neighbors of the new play points 803so that the neighbors can adjust their Front_Buffer_Size accordingly.Finally, client 103 needs to inform tracker 104 of its new play point803. On the other hand, a large change in client's play point 803requires client 103 to (i) disconnect its existing neighbors, (ii)contact tracker 104 to obtain a new list of peers whose current playpoints 803 are close to client's 103 new play point 803, and (iii)connect to new neighbors.

In connection with supporting video conference, the system of thepresent invention can be extended to support video conferencing with thefollowing modifications.

In comparison with live streaming, video conferencing has three keydifferences: (i) instead of having content source server(s), multipleparticipating clients 103 of the conference will generate video andaudio data that need to be disseminated to a subset of participants.Hence, the communication is many-to-many (as opposed to one-to-many inthe case of live streaming); (ii) video conferencing imposes much morestringent performance constraints on audio and video streams; and (iii)the number of participants in a video conference is typically muchsmaller than the number of clients 103 in a live streaming channel.

In order to support video conferencing, the principles of the presentinvention implement a pull-based approach and a push-based approach asdiscussed below.

Video conference can be considered as a special case of live streaming,where each participant publish their audio/video streams to conferenceserver(s) 102, which in turn disseminates the audio/video streams to theother participants 103 who are interested in listening to or watchingthe streams. Therefore, the mechanism developed for live streaming canbe directly applied to support video streaming. In this scheme, clients103 need to actively pull (i.e., request) pieces from either peers orcontent source 102. This is referred to herein as the “pull-basedapproach.”

In addition to applying the above mechanism to support videoconferencing, an alternative scheme based on random tree pushing isdeveloped to further reduce network delay. The goal of random tree baseddistribution scheme is to develop a shallow tree that has enoughbandwidth to distribute the content to all the participants. The treeshould be shallow since the network delay increases with the depth ofthe tree. One way is to optimize tree construction based on networktopology and traffic. However, this requires up-to-date globalinformation about the network topology and traffic and frequentadaptation to the changes in the topology and traffic. In order toachieve high efficiency without requiring global information orcoordination, the following method (random tree based pushing) may beused as discussed below in connection with FIG. 12.

FIG. 12 is a method 1200 for reducing network delay using random treepushing in accordance with an embodiment of the present invention.

Referring to FIG. 12, in conjunction with FIG. 1, in step 1201, thesource client 103, who generates the audio/video stream, randomly picksa set of nodes (other clients 103) as the next hop forwarders for agiven piece of content. Nodes are selected as next hops with aprobability proportional to its upload bandwidth, since nodes withhigher bandwidth should be preferred as forwarders.

In step 1202, the source client 103 keeps adding next hops until thetotal upload bandwidth of all next hops is no less than the bandwidthrequired to deliver to all the remaining receivers. More formally, let Cbe the source client and let P[1], P[2], . . . , P[n] be the set ofreceivers. Let bw[k] be the upload bandwidth of P[k]. Let p be a newpiece to be disseminated. The source client C performs the following:(i) C first computes randomized weightsW[k]=log(uniform(P[k],C,p))/bw[k], where uniform(P[k],C,p) is a pseudorandom number uniformly distributed between 0 and 1 and is generatedwith pair (P[k], C) as the random seed; (ii) C sorts all the P[k] indescending order of W[k] (Let P[k₁], P[k₂], . . . P[k_(n)] be the sortednodes (so we have W[k₁]≧W[k₂]≧ . . . ≧W[k_(n)])); and (iii) C finds thesmallest m such that bw[k₁]+ . . . +bw[k_(m)]≧(n−m)*Data_Rate[C], whereData_Rate[C] is the data rate of the video stream generated by C. C thendesignate P[k₁], . . . , P[k_(m)] as its next-hop forwarders.

In step 1203, the source client 103 further partitions the receivers inthe current video session and assigns each receiver to one of the nexthops, which will be responsible for forwarding the video stream to theassigned receiver either directly or through a multi-hop path. Thenumber of receivers assigned to the next hop is proportional to the nexthop's bandwidth. For example, suppose there are 9 receivers and 2next-hop forwarders: node A has 2 Mbps and node B has 1 Mbps. Node A isresponsible for delivering to 6 receivers and node B is responsible fordelivering to 3 receivers.

Formally, let P[k₁], . . . , P[k_(m)] be the set of m next-hopforwarders determined in step 1101. Let P[k_(m+1)], . . . , P[k_(n)] bethe set of (n−m) receivers (i.e., non-forwarders). The source client 103partitions the (n−m) receivers into m sets: S₁, . . . , S_(m), where thesize of the set S_(j) (j=1, . . . , m) is proportional to bw[k_(j)] andforwarder P[k_(j)] is responsible for forwarding piece p to receivers inset S_(j). The source client 103 then sends a data message to eachforwarder P[k_(j)], where the data message contains piece p as well asthe set of receivers S_(j). If the source client 103 does not haveenough bandwidth to forward piece p to all the forwarders in a timelyfashion, then client 103 has the option of forwarding a copy of piece pto the conference server(s) and let the conference server(s) forwardpiece p to some next-hop forwarders.

In step 1204, after a next-hop forwarder P[k_(j)] receives piece p, setS_(j), P[k_(j)] can directly forward piece p to all the receivers in setS_(j). Alternatively, it is possible for P[k_(j)] to pick its ownnext-hop forwarders using the same probabilistic approach as in step1201, and assigns the receivers to the forwarder as described in step1203. This process is repeated recursively until the video reaches allthe receivers.

Note that in the above steps, next-hop forwarders are selected from thecurrent receivers interested in receiving video from the source client103. Method 1200 can be easily extended to include other active users(who are not interested in watching client's 103 video stream) ascandidate next-hop forwarders.

Also it is noted that the push-based scheme and the pull-based schemeare not mutually exclusive. They can be easily combined into a hybridscheme. For example, pieces are primarily distributed using thepush-based approach. Meanwhile, client 103 can request (i.e., pull)missing pieces from either its neighbors or the conference server (e.g.,content distribution network server 102).

In some implementations, method 1200 may include other and/or additionalsteps that, for clarity, are not depicted. Further, in someimplementations, method 1200 may be executed in a different orderpresented and that the order presented in the discussion of FIG. 12 isillustrative. Additionally, in some implementations, certain steps inmethod 1200 may be executed in a substantially simultaneous manner ormay be omitted.

Although the method, system and computer program product are describedin connection with several embodiments, it is not intended to be limitedto the specific forms set forth herein, but on the contrary, it isintended to cover such alternatives, modifications and equivalents, ascan be reasonably included within the spirit and scope of the inventionas defined by the appended claims.

1. A method for efficiently distributing video content, the methodcomprising: requesting from a tracker unit to one of join an existinglive streaming channel, join a video on demand streaming channel andjoin a video conference, wherein said tracker unit is configured to keeptrack of active peers in a peer-to-peer network; receiving a list ofactive peers participating in one of said live streaming channel, saidvideo on demand streaming channel and said video conference from saidtracker unit; connecting, by a processor, to a subset of peers in saidlist provided by said tracker unit to become neighbors in saidpeer-to-peer network; and receiving a missing piece of video contentfrom one of said neighbors in said peer-to-peer network or from acontent distribution network server based on where said missing piece ofvideo content is to be stored in a video buffer.
 2. The method asrecited in claim 1 further comprising: requesting periodically from saidtracker unit for additional peers to form part of said peer-to-peernetwork if a number of said neighbors in said peer-to-peer network isbelow a threshold number.
 3. The method as recited in claim 1 furthercomprising: sending a notification to said tracker unit to leave saidpeer-to-peer network; and disconnecting all said neighbors in saidpeer-to-peer network.
 4. The method as recited in claim 3 furthercomprising: removing an indication of a client by said tracker unit fromsaid list of active peers in response to receiving said notificationfrom said client.
 5. The method as recited in claim 1 furthercomprising: connecting to one or more additional peers to become saidneighbors in said peer-to-peer network if a number of said neighbors insaid peer-to-peer network is below a threshold.
 6. The method as recitedin claim 1 further comprising: removing a peer from said peer-to-peernetwork if said peer has not provided a message within a duration oftime.
 7. The method as recited in claim 1 further comprising: removing apeer from said peer-to-peer network if a rate of loss video contentprovided by said peer exceeds a threshold.
 8. The method as recited inclaim 1, wherein said video buffer comprises a back buffer, a sourceprotection window, an urgent window and a front buffer, wherein saidback buffer comprises recently played pieces of video content, whereinsaid source protection window comprises pieces of video content whosedeadlines are within a first number of pieces from a current play point,wherein said urgent window comprises a second number of pieces of videocontent after an end of said source protection window, wherein saidfront buffer comprises a third number of pieces of video content afteran end of said urgent window.
 9. The method as recited in claim 8,wherein pieces of video content in said front buffer are later in timethan pieces of video content in said urgent window which are later intime than pieces of video content in said source protection window whichare later in time than pieces of video content in said back buffer. 10.The method as recited in claim 8, wherein missing pieces of videocontent in said source protection window are fetched from said contentdistribution network server.
 11. The method as recited in claim 8,wherein missing pieces of video content in said urgent window arefetched from said neighbors in said peer-to-peer network in anearliest-deadline-first fashion.
 12. The method as recited in claim 8,wherein missing pieces of video content in said front buffer are fetchedfrom one of said content distribution network server and said neighborsin said peer-to-peer network.
 13. The method as recited in claim 12,wherein said missing pieces of video content are fetched from saidneighbors in said peer-to-peer network in a rarest-latest-first fashion.14. The method as recited in claim 8, wherein a size of said frontbuffer is based on a difference between a neighbor's play point and aplay point of a client.
 15. The method as recited in claim 8 furthercomprising: readjusting a size of said front buffer after performing oneof a forward and a backward seek operation if a new play point is notwithin an upper bound limit of said front buffer.
 16. The method asrecited in claim 1 further comprising: selecting a number of peers tofetch a missing piece of video content from said content distributionnetwork server; and disseminating said fetched missing piece of videocontent to other peers in a peer-to-peer fashion in said peer-to-peernetwork.
 17. The method as recited in claim 1 further comprising:receiving information about said neighbors in said peer-to-peer network,wherein said information comprises geographical location and uploadbandwidth; computing a randomized weight for said upload bandwidth ofsaid neighbors; and selecting a subset of said neighbors to fetch amissing piece of video content from said content distribution networkserver based on said randomized weight.
 18. The method as recited inclaim 1 further comprising: injecting a missing piece of video contentfrom said content distribution network server when a neighbor in saidpeer-to-peer network has insufficient upload bandwidth.
 19. The methodas recited in claim 18 further comprising: exchanging piece availabilityvia a bitmap with said neighbors in said peer-to-peer network; computinga per-piece bandwidth deficit; computing a cumulative bandwidth deficit;computing a number of copies that need to be injected from said contentdistribution network server into a client's 1-hop neighborhood; andselecting a subset of said neighbors in said client's 1-hop neighborhoodto inject said missing piece of video content from said contentdistribution network server.
 20. The method as recited in claim 1further comprising: implementing a token bucket algorithm to control anamount of video content uploaded.
 21. The method as recited in claim 1further comprising: implementing an additiveincrease/multiplicative-decrease algorithm to control an amount of videocontent downloaded.
 22. The method as recited in claim 1 furthercomprising: receiving said list of active peers that are within a firstnumber of minutes from a play point of a client.
 23. The method asrecited in claim 1 further comprising: requesting one or more missingpieces of video content from one or more of said neighbors in saidpeer-to-peer network or from said content distribution network server.24. A computer program product embodied in a computer readable storagemedium for efficiently distributing video content, the computer programproduct comprising the programming instructions for: requesting from atracker unit to one of join an existing live streaming channel, join avideo on demand streaming channel and join a video conference, whereinsaid tracker unit is configured to keep track of active peers in apeer-to-peer network; receiving a list of active peers participating inone of said live streaming channel, said video on demand streamingchannel and said video conference from said tracker unit; connecting toa subset of peers in said list provided by said tracker unit to becomeneighbors in said peer-to-peer network; and receiving a missing piece ofvideo content from one of said neighbors in said peer-to-peer network orfrom a content distribution network server based on where said missingpiece of video content is to be stored in a video buffer.
 25. Thecomputer program product as recited in claim 24 further comprising theprogramming instructions for: requesting periodically from said trackerunit for additional peers to form part of said peer-to-peer network if anumber of said neighbors in said peer-to-peer network is below athreshold number.
 26. The computer program product as recited in claim24 further comprising the programming instructions for: sending anotification to said tracker unit to leave said peer-to-peer network;and disconnecting all said neighbors in said peer-to-peer network. 27.The computer program product as recited in claim 24 further comprisingthe programming instructions for: connecting to one or more additionalpeers to become said neighbors in said peer-to-peer network if a numberof said neighbors in said peer-to-peer network is below a threshold. 28.The computer program product as recited in claim 24 further comprisingthe programming instructions for: removing a peer from said peer-to-peernetwork if said peer has not provided a message within a duration oftime.
 29. The computer program product as recited in claim 24 furthercomprising the programming instructions for: removing a peer from saidpeer-to-peer network if a rate of loss video content provided by saidpeer exceeds a threshold.
 30. The computer program product as recited inclaim 24, wherein said video buffer comprises a back buffer, a sourceprotection window, an urgent window and a front buffer, wherein saidback buffer comprises recently played pieces of video content, whereinsaid source protection window comprises pieces of video content whosedeadlines are within a first number of pieces from a current play point,wherein said urgent window comprises a second number of pieces of videocontent after an end of said source protection window, wherein saidfront buffer comprises a third number of pieces of video content afteran end of said urgent window.
 31. The computer program product asrecited in claim 30, wherein pieces of video content in said frontbuffer are later in time than pieces of video content in said urgentwindow which are later in time than pieces of video content in saidsource protection window which are later in time than pieces of videocontent in said back buffer.
 32. The computer program product as recitedin claim 30, wherein missing pieces of video content in said sourceprotection window are fetched from said content distribution networkserver.
 33. The computer program product as recited in claim 30, whereinmissing pieces of video content in said urgent window are fetched fromsaid neighbors in said peer-to-peer network in anearliest-deadline-first fashion.
 34. The computer program product asrecited in claim 30, wherein missing pieces of video content in saidfront buffer are fetched from one of said content distribution networkserver and said neighbors in said peer-to-peer network.
 35. The computerprogram product as recited in claim 30, wherein said missing pieces ofvideo content are fetched from said neighbors in said peer-to-peernetwork in a rarest-latest-first fashion.
 36. The computer programproduct as recited in claim 30, wherein a size of said front buffer isbased on a difference between a neighbor's play point and a play pointof a client.
 37. The computer program product as recited in claim 30further comprising the programming instructions for: readjusting a sizeof said front buffer after performing one of a forward and a backwardseek operation if a new play point is not within an upper bound limit ofsaid front buffer.
 38. The computer program product as recited in claim24 further comprising the programming instructions for: selecting anumber of peers to fetch a missing piece of video content from saidcontent distribution network server to be disseminated to other peers ina peer-to-peer fashion in said peer-to-peer network.
 39. The computerprogram product as recited in claim 24 further comprising theprogramming instructions for: receiving information about said neighborsin said peer-to-peer network, wherein said information comprisesgeographical location and upload bandwidth; computing a randomizedweight for said upload bandwidth of said neighbors; and selecting asubset of said neighbors to fetch a missing piece of video content fromsaid content distribution network server based on said randomizedweight.
 40. The computer program product as recited in claim 24 furthercomprising the programming instructions for: injecting a missing pieceof video content from said content distribution network server when aneighbor in said peer-to-peer network has insufficient upload bandwidth.41. The computer program product as recited in claim 40 furthercomprising the programming instructions for: exchanging pieceavailability via a bitmap with said neighbors in said peer-to-peernetwork; computing a per-piece bandwidth deficit; computing a cumulativebandwidth deficit; computing a number of copies that need to be injectedfrom said content distribution network server into a client's 1-hopneighborhood; and selecting a subset of said neighbors in said client's1-hop neighborhood to inject said missing piece of video content fromsaid content distribution network server.
 42. The computer programproduct as recited in claim 24 further comprising the programminginstructions for: implementing a token bucket algorithm to control anamount of video content uploaded.
 43. The computer program product asrecited in claim 24 further comprising the programming instructions for:implementing an additive increase/multiplicative-decrease algorithm tocontrol an amount of video content downloaded.
 44. The computer programproduct as recited in claim 24 further comprising the programminginstructions for: receiving said list of active peers that are within afirst number of minutes from a play point of a client.
 45. The computerprogram product as recited in claim 24 further comprising theprogramming instructions for: requesting one or more missing pieces ofvideo content from one or more of said neighbors in said peer-to-peernetwork or from said content distribution network server.
 46. A system,comprising: a memory unit for storing a computer program for efficientlydistributing video content; and a processor coupled to said memory unit,wherein said processor, responsive to said computer program, comprisescircuitry for requesting from a tracker unit to one of join an existinglive streaming channel, join a video on demand streaming channel andjoin a video conference, wherein said tracker unit is configured to keeptrack of active peers in a peer-to-peer network; circuitry for receivinga list of active peers participating in one of said live streamingchannel, said video on demand streaming channel and said videoconference from said tracker unit; circuitry for connecting to a subsetof peers in said list provided by said tracker unit to become neighborsin said peer-to-peer network; and circuitry for receiving a missingpiece of video content from one of said neighbors in said peer-to-peernetwork or from a content distribution network server based on wheresaid missing piece of video content is to be stored in a video buffer.47. The system as recited in claim 46, wherein said processor furthercomprises: circuitry for requesting periodically from said tracker unitfor additional peers to form part of said peer-to-peer network if anumber of said neighbors in said peer-to-peer network is below athreshold number.
 48. The system as recited in claim 46, wherein saidprocessor further comprises: circuitry for sending a notification tosaid tracker unit to leave said peer-to-peer network; and circuitry fordisconnecting all said neighbors in said peer-to-peer network.
 49. Thesystem as recited in claim 46, wherein said processor further comprises:circuitry for connecting to one or more additional peers to become saidneighbors in said peer-to-peer network if a number of said neighbors insaid peer-to-peer network is below a threshold.
 50. The system asrecited in claim 46, wherein said processor further comprises: circuitryfor removing a peer from said peer-to-peer network if said peer has notprovided a message within a duration of time.
 51. The system as recitedin claim 46, wherein said processor further comprises: circuitry forremoving a peer from said peer-to-peer network if a rate of loss videocontent provided by said peer exceeds a threshold.
 52. The system asrecited in claim 46, wherein said video buffer comprises a back buffer,a source protection window, an urgent window and a front buffer, whereinsaid back buffer comprises recently played pieces of video content,wherein said source protection window comprises pieces of video contentwhose deadlines are within a first number of pieces from a current playpoint, wherein said urgent window comprises a second number of pieces ofvideo content after an end of said source protection window, whereinsaid front buffer comprises a third number of pieces of video contentafter an end of said urgent window.
 53. The system as recited in claim52, wherein pieces of video content in said front buffer are later intime than pieces of video content in said urgent window which are laterin time than pieces of video content in said source protection windowwhich are later in time than pieces of video content in said backbuffer.
 54. The system as recited in claim 52, wherein missing pieces ofvideo content in said source protection window are fetched from saidcontent distribution network server.
 55. The system as recited in claim52, wherein missing pieces of video content in said urgent window arefetched from said neighbors in said peer-to-peer network in anearliest-deadline-first fashion.
 56. The system as recited in claim 52,wherein missing pieces of video content in said front buffer are fetchedfrom one of said content distribution network server and said neighborsin said peer-to-peer network.
 57. The system as recited in claim 52,wherein said missing pieces of video content are fetched from saidneighbors in said peer-to-peer network in a rarest-latest-first fashion.58. The system as recited in claim 52, wherein a size of said frontbuffer is based on a difference between a neighbor's play point and aplay point of a client.
 59. The system as recited in claim 52, whereinsaid processor further comprises: circuitry for readjusting a size ofsaid front buffer after performing one of a forward and a backward seekoperation if a new play point is not within an upper bound limit of saidfront buffer.
 60. The system as recited in claim 46, wherein saidprocessor further comprises: circuitry for selecting a number of peersto fetch a missing piece of video content from said content distributionnetwork server to be disseminated to other peers in a peer-to-peerfashion in said peer-to-peer network.
 61. The system as recited in claim46, wherein said processor further comprises: circuitry for receivinginformation about said neighbors in said peer-to-peer network, whereinsaid information comprises geographical location and upload bandwidth;circuitry for computing a randomized weight for said upload bandwidth ofsaid neighbors; and circuitry for selecting a subset of said neighborsto fetch a missing piece of video content from said content distributionnetwork server based on said randomized weight.
 62. The system asrecited in claim 46, wherein said processor further comprises: circuitryfor injecting a missing piece of video content from said contentdistribution network server when a neighbor in said peer-to-peer networkhas insufficient upload bandwidth.
 63. The system as recited in claim62, wherein said processor further comprises: circuitry for exchangingpiece availability via a bitmap with said neighbors in said peer-to-peernetwork; circuitry for computing a per-piece bandwidth deficit;circuitry for computing a cumulative bandwidth deficit; circuitry forcomputing a number of copies that need to be injected from said contentdistribution network server into a client's 1-hop neighborhood; andcircuitry for selecting a subset of said neighbors in said client's1-hop neighborhood to inject said missing piece of video content fromsaid content distribution network server.
 64. The system as recited inclaim 46, wherein said processor further comprises: circuitry forimplementing a token bucket algorithm to control an amount of videocontent uploaded.
 65. The system as recited in claim 46, wherein saidprocessor further comprises: circuitry for implementing an additiveincrease/multiplicative-decrease algorithm to control an amount of videocontent downloaded.
 66. The system as recited in claim 46, wherein saidprocessor further comprises: circuitry for receiving said list of activepeers that are within a first number of minutes from a play point of aclient.
 67. The system as recited in claim 46, wherein said processorfurther comprises: circuitry for requesting one or more missing piecesof video content from one or more of said neighbors in said peer-to-peernetwork or from said content distribution network server.